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Remarks: 

Claims 2-9 and 30-37 were rejected under §102 as being anticipated by the INSS article. 

The rejection stated that the fact that INSS maintains offer history data to determine if 
an optimal agreement has been reached or to suggest a Pareto-Optimal agreement f or 
both parties is indicative of the fact that INSS itself analyzes and understands; the 
negotiation terms. 

Applicants respectfully disagree. INSS is not a negotiations system, it is not analyzing 
terms during iterative processing to understand the purpose of the terms, it does not 
identify which terms relate to which party/ it does not recognize changes in terms, and 
it does not recognize at least one party as a deciding entity. 

The INSS system does not do any analysis to understand the purpose of terms to 
generate a Pareto-optimal agreement for both parties, nor does it identify which terms 
and inputs relate to which party and are significant to the Pareto-optimal analysis- The 
INSS article makes dear in discussing how to "Describe a new negotiation case", that all 
the terms and values for the mock negotiations are provided to the INSS system by 
whoever builds the case before any m ocknegotiation beg ins. As will be seen, this 
eliminates the need for any analysis of terms to understand their purpose, whether to 
simulate a negotiation, to generate a Pareto-optimal agreement or to identify which 
terms and inputs are signiiicant to a Pareto-optimal analysis. 
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In fact the INS5 article makes it quite clear that the values assigned to terms (called 
options (values) and issues (similar to terms) to INSS) are irrelevant to its Pareto 
"analysis". While sounding complex, a Pareto-optimal agreement is nothing more than 
one which could not be improved for one party without making it worse for the other. 
Historically, negotiation support systems (NSS) might have attempted to perform an. 
objective analysis of the values of the terms in an agreement to determine this. That is, 
they might have tried to find an agreement say, with better price terms for both parties 
than the one they agreed ttpon* This could be useful if price is the most important 
factor for both parties. However, it is often the case that objective measures such as 
price or delivery times are not as important to the parties as other, more subjective 
factors. 

Thus some modern NSS systems typically do not attempt objective analysis of terms at 
all. Instead, they rely solely, as INSS expressly does (as will be seen below), on 
subjective ratings which the users supply. Thus it is irrelevant which agreement might 
"objectively" be better or optimal for both parties. It is also irrelevant which terms are 
significant for Pareto optimality for two reasons* Firsi^ INSS doesn't analyze the terms 
(issues and options in INSS), for Pareto analysis— it only looks at ratings. Second, the 
users of INSS are asked to rate all the terms and combinations and values — thus no one 
term (issue) or value (option) is more significant than another — all get ratings. As will 
be seen, this makes the computation of Pareto-optimattty a simple arithmetic problem 
of comparing ratings that does not require analysing terms (issues and options) at all. 
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To see this, it helps to understand how INSS works and its tenninology. At INSS page 6, 

under the heading "Describe a new negotiation case", the article states: 

"You can request that a new negotiation case be set up for you by submitting this form* 
Specify the issues 

At a minimum you must specify the names of the issues that will be negotiated/ j^Ltfoe 
options that e ach issue mav take . For example: 

"Annual salary" - "50,000", "70,000" or "100,000" dollars. 
Vacation" - 2, 4 or 6 weeks/' [Underlining emphasis added.] 

In the glossary of the INSS article on page 19, an issue is defined as: 

"A topic of discussion that is of particular interest in a negotiation. Each issue has a 
range of alternatives or options, one of which must ultimately be agreed upon by the 
negotiators in order to achieve a compromise/' 



And at Page 20, an option is defined as: 

"One of the alternative values that an issue c an take. For example, the issue "Tolerable 
product failure rate" may have the options "3%", "5%" and "10%". 

In other words, an issue is similar to a term in a real negotiation. However, because this 
is a simulation using a simulation model or case, as seen here, all the possible values for 
an issue (term) must be defined in advance- In this instance, these values are supplied 
as what INSS calls "options"- As noted above> the article says that to create a new case 
you must at a minimum,, s pecify the names of the issues that will be negotiated, and the 
options that each issue may take . 
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Again, on Page 8, under the headings "Using INSS: An Example", and "Negotiations 
between Maki and Suny", the article describes a sample negotiation case which has 
been set up by the article's authors to show how to use INSS: 

"There are only two issues in this simple negotiation: the price of the aircraft and the 
terms of the warranty. It has been established that the normal price of this aircraft is in 
the range of $300,000 to $320,000. Hie sensible increase is of $10,000. Thus, the price 
options are $300,000, $310,000, and $320,000. In this industry there are four types of 
warranty typically available. Hie options are: no warranty, a 6 month, one year, and a 2 
year warranty. 

Both negotiators analyze the two issues and their associated options in terms of their 
relevance to their respective organizations and move to the ore-negotiation phase. 
[Underlining emphasis added.) 



As the rest of this example shows, all the possible terms and all the possible values 
(issues and options in DSTSS terminology) of this negotiation are already in the model as 
some combination, of the two issues (terms) with their respective options (values). 



In this aircraft example, from the INSS article there would be 12 possible sets of issues 
and options that would make up an aircraft model: 
AIRCRAFT MODEL: 



Package No. 


Issue 1 


Issue 2 


Maki's rating 


Suny's rating 
70* 


1 


$300,000 


0 


30* 


2 


$300,000 


6 mos. 


15* 


80* 


3 


$300,000 


1 yr 


20* 


100* 


4 


$300,000 


2yr 


0* 


90* 


5 


$310,000 


0 


50* 


40* 


6 


$310,000 


6 mos. 


40* 


50* 


7 


$310,000 


lyr 


30* 


60* 


8 


$310,000 


2yr 


25* 


30* 


9 


$320,000 


0 


100 


0* 


10 


$320,000 


6 mos. 


75 


20* 


11 


$320,000 


1 yr 


90 


15* 


12 


$320,000 


2yr 


60 


10* 


* Ratings marked with an asterisk are hypothetical and not taken 


from the INSS article- 
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Again, in the glossary at Page 20, a package is defined as 

"A particular combination of options that has been selected across all the isguqg. For 



Price 


3000$ 


Payment 


Upon Delivery 


Failure rate 


5% 



Thus it can be seen that for each case used for the mock negotiations using the 1NSS 
simulation system, all the variables are known ahead of time and inserted intQ-thejasg 
or model by issue name and option value prior to any mode negotiation. For the 
aircraft model, issue (term) one can have three options (values)— $300,000, $310,000 or 
$320,000. Issue (term) 2 can have four options (values): 0, 6 months, 1 year or 2 years> 
The combination of three options (values) for issue 1 and four options (values) for issue 
2 results in 12 possible outcomes or packages* as seen above- They can be stored in the 
computer in a simple table similar to aircraft model shown above, or in similar 
arrangements in a file. Not only is there no disclosure of analysis by the 1NSS si mulator 
to understand the purpose of the terms in the IN5S article, there is no need or 
requirement for analysis to understand the purpose of the terms, or in the case of INSS, 
the issues, since all o£ their possible values (options) must already be known ahead of 
time by the simulator* 

In the two examples cited in the INSS article, it does not matter whether the name of 
issue 1 in case 1 is annual salary or as in the aircraft model, issue 1 is named price. What 
matters is that all the possible options or values for that issue number are specified 
ahead of time so the case can be built. The simulator neither knows nor cares that it is 
simulating a price negotiation as opposed to a salary negotiation* It does not analyze 
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terms or need to analyze them, during a mock negotiation, since they are predefined in 
the model as issues and options- All that is needed for the INSS simulator to operate is a 
set of pre-defined issues (terms) and options (values). 

This pre-definition is made even clearer on Page 17, where the INSS article states, under 

the heading "INSS FAQ (Frequently Asked Questions)", question no. 2: 

"2. I have requested a negotiation already. When can I start my negotiation? 
Your negotiation will be set up typically within 2-3 days. INSS wiU notify you via e- 
mail, (specifying your negotiation name and user name), after which you can start your 
negotiation right away/' 



The set up mentioned here refers back to Page 6, ''Describe a new negotiation case, 
where the article states, "You can request that a new negotiation case be set up for you 
by submitting this form." 



Neither of the players who use the INSS simulator for a mock negotiation supply the 
values (options) for the issues during their mock negotiations. These values have 
already been programmed into the case they are using before the mock negotiation 
begins. In fact unless one of the players is the one who requested that the case be 
constructed, neither of the players provides any input at all for "terms" (issues and 
their options) when he or she uses the INSS simulator. 

Page 8, for example, shows the aircraft case which has been set up by the authors to 
show how to use INSS. In this example, players "Maki" and "Suny" do not supply any 
of the options for issues I and Z Since the "terms" (issues) and all possible values 
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(options) they can have an; pre-programmed into a case before a mock negotiation can 
begin, there is no need for, and no disclosure of any analysis done by the INSS 
simulator to understand the purpose of the terms (issues). Unlike applicants' invention, 
which analyzes terms during iterations of a negotiation to understand their purpose, it 
is irrelevant to the INSS simulator whether an "issue" is a price term or a warranty term 
or a salary term or a vacation term. INSS only deals with predefined options for named 
issues as these are stored in the model* 



Nor is there any disclosure of which terms (issues) relate to which party either before 
mock negotiation begins or during it. The values (options) for all the terms (issues) are 
supplied in advance by the person who creates the case, not by the parties during a 
mock negotiation. Since the person, who builds the case need not be, and, more 
frequently, is not likely to be, either of the players who use the simulation case, it is 
dear that INSS also does not relate the terms (issues) to either player. In the aircraft case 
example, all the values (options) for all the terms (issues) have been supplied in 
advance by the authors, to show how to use INSS- There is no way in which INSS can 
relate any of the price ($320,000) or warranty (2 years) option values to player "Maki" 
or "Suny", since neither player supplied them. Therefore, the rejection is also incorrect 
in stating that INSS must identify which terms (issues) relate to which party* 

What the players do supply are subjective ratings for the issues and values, but this, 
too, is done befpjrg any mock negotiation can begin and in such a way that the simulator 
does not provide any analysis. 
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At page 2, for example, under the heading "Using INSS" it states: 

There are three basic steps that are usually followed in any negotiation: 
Preparation for the negotiation, during which you study the situation, identify the 
stakeholders, arid develop a very clear understanding of the issues and interests 
involved- To help you do this step, INSS provides you with a detailed description of 
your negotiation case and then guides you through a sequence of pages on which you 
tell the system how important each issue and alternative is to you. This step is also 
called preference elicttation. The informatiorLSO obtained is used by I NSS in the next 
step to give you helpful feedback when constructing new offers or evaluating your 
counterpart's offers / 7 [Underlining emphasis added] 



Again, this information about how each player rates the data is collected before a mock 
negotiation begins. At Pages 8 and 9, under the headings "Using INSS: An Example", 
and ''Preparation", the article describes three types of ratings the players are asked to 
do: Issue rating, Option rating and package evaluation. 



In the example on page 8, of the aircraft case, the players Maki and Suny are first asked 
to rate the two issues. As the article notes t 

"Maki feels that price is far more important than warranty. Therefore, she assigns 70 
points to price and 30 to payment {sic — this presumably should have been warranty}. 
Although Maki does not know it Suny feels that each issue is equally important and so 
Suny assigns 50 points to each" 



On Page 9, under the heading Option rating, it is stated: 

" After rating the issues, the options in each issue must also be rated similarly- In the 
INSS system, for each issue at least one option must be assigned the maximum rating 
for the issue and at least one option must be assigned a rating of zero /' [Emphasis 
added.] 



Note that this makes it even clearer that all the values (options) for the variables of a 
negotiation have been supplied in the case beforehand. What the players must do is rate 
the subjective importance to them of these issues (terms) and these actual values 
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(options). This is seen in the two tables showing player Maki's ratings for the issue 1 
and issue 2 options. 

At this point, since all the possible values (options) for the only two issues in this case 
are known, 1NSS also asks the players to evaluate packages — i.e. combinations of issues 
and options, such as those Applicants' attorney has listed above in the aircraft model. 
Package 9 in that table is the sam e as the first package listed in the INSS article on page 
9 for Maki — namely issue 1 having an option of $320,000 and issue 2 having an option 
value of no warranty- Maki's rating of this package is 100. 

As INSS makes dear, the ratings by the players must be also be done before any mock 
negotiation can begin. 

The rejection of Applicants' claims suggests that INSS sends and receives terms along a 
communications path and that this is involved in the determination of Pareto- 
optimality. Applicants believe they have shown that in fact neither party using INSS 
enters issues, options or ratings during a mock negotiation. All possible issues and 
options were entered by the person who created the case beforehand. Thus INSS cannot 
identify which issues and options relate to which party, since there is no way for a 
person creating a case to indicate this and no way for the players to do so either. 

INSS also does not analyze terms to understand which are significant to a Pareto- 
optimal outcome- By having the players rate the issues and options, the users or players 
specify the data (their subjective ratings) to be used for determining a Pareto-optimal 
outcome — not the INSS system. Applicants respectfully submit that Pareto-optimality 
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sounds more complicated than it is. In this context it simply means that based on the 
subjective ratings the players provide ahead of time for each predefined package, there 
could be one or more packages that are better for both players (have a higher subjective 
rating for both players without making either player worse off) than tine one they may 
initially choose, 



Note that it is explicitly stated in INSS that this notion of "better' 7 does not take into 
account any of the values supplied for the issues and options. It does not matter what 
the issue 1 and issue 2 values actually are for the INSS system in the aircraft model 
example cited. All that matters for a Pareto-optimal result is that both players may have 
subjectively rated one or more packages as better than a package they have agreed 
upon. 



This is made clear at Page 12, under the heading "Post-Settlement": 
"Efficient packages 

In some negotiations it may happen that the parties reach an agreement but there is {sic) 
one or more packages which are better than the accepted offer for both sides. Note that 
better is measured with the parties utility functions. Thus, there may be a package for 
which the two ratings axe higher than the packag e that has been accepted, 

INSS has a post-settlement stage, during which it uses the preference information 
provided by each user to determine whether it is possible to construct packages that are 
better for the two parties-/' 
Utility function is defined in the glossary as: 

" A utility ftmrtinn is a subjective measurement that expresses the relative value of 
di ffi rrpr\t package (sicl by using a numerical scale. The numerical scale used is arbitrary- 
It typically ranges either from 0 to 1 or from 1 to 100. The minimum number expresses 
the least desirable and least preferred package. The highest number represents the most 
desirable and preferred package. " [Underlining emphasis added] 

In other words, the utility function INSS uses is simply the subjective ratings the players 
provide for the pre-defined packages. 
Page 11 of 27 
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Tn the aircraft model example above, if the parties had agreed upon Package 12 during 
the mock negotiation, for which their subjective ratings are 60 and 10 respectively, it can 
be seen that Package 10 would be Pareto-optimally "better" for both of them because 
each of them has subjectively rated Package 10 higher than Package 12- As mentioned 
above, these ratings are the player's subjective views of the importance of the issues 
(terms) and options (values). 

Thus, it is not necessary, nor does INSS disclose or render obvious a need to understand 
the purpose of terms (issues) or values (options) in order to determine a Pareto-optimal 
package* It is done solely on the basis of subjective ratings supplied in advance for 
packages defined in advance. As described at Page 12, the determination of such an 
optimal package is not done during iterative processing of the mock negotiation, but 
after the conclusion of the mock negotiation. To determine if a package is Pareto- 
optimal, all INSS has to do is compare the parties' ratings for the various packages to 
see if any package has higher ratings for both of them* If none of the packages have 
higher ratings for both parties, then the one they agreed on in the mock negotiation is 
Pareto-optimal for them. This is a simple arithmetic function and has nothing to do with 
analyzing the issues (terms) or options (values) in the mock negotiation. 

The rejection of applicants' claims in view of INSS further states that INSS processing 
includes: 

"recognizing any changes in the terms „/' . 
Page 12 of 27 
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Applicants respectfully disagree again. As applicants believe their above analysis 
shows, there are no Aanges in the terms to be detected or recognized b y IN3S. All 
possible term values (issues and options) are specified ahead of time, when the issues 
and options are specified so the case can be built. The playere do not enter new issues or 
options during a mock negotiation, they select from packages or the predefined options 
to construct "offers''. 

This is made dear at page 15, under the heading "3.Using INSS", starting at number 6: 

"6. Rate the packag es. A number of packages are displayed for you. Each package has a 
rating- Check if you agree with the ratings. If you disagree with the ratings of any of the 
packages change them in the box on the right-hand side of the table. Please do not try to 
manipulate these rankings as they are used for their own benefit 

From now on every offer (a package) which you want to consider and present to you* 
partner will show a rating based on your preferences. Any offers sent to you by your 
partner will also show a rating. Remember, this rating reflects your and only your 
opinion- Your partner does not know your opinion nor can he or she see your ratings. 

7. Fill out the pre-negotiation questionnaire , 

8. Make an offer to your partner using the menus in the offer-box. You can also send 
messages to your partner using the message-box/' [Holding added] 

It appears from this that the players do not enter option values such as $310,000 in an 
offer screen during the mock negotiation. Instead, as the above excerpt from the INSS 
article says, the INSS simulator presents the players with a menu of the predefined 
packages, from which they select one — such as Package 12, for example, to use as an 
"offer". 

Thus, an "offer" of $310,000 and 0 warranty, is not a change in terms or a new term. It is 
one of the packages which was predefined when the case was set up initially. It is also a 
package which each of the players has already rated during the pre-negotiation rating 
Page 13 of 27 
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phase. These ratings are presumably also stored in connection with the predefined 
packages. This is why it is a simple matter for the INSS system to "present" that offer to 
the other player, and along with it show to the other player that player's (Suny in this 
example) rating for that same predefined package. 

For example, in the aircraft model for the airplane example, predefined Package 9 has a 
rating of 100 for Maki and a rating of 0 for Suny- If Maki "offers" package 9 to Suny, the 
INSS simulator does not hiave to recognize any changes in order to present Package 9 to 
Suny. There are no changes to Package 9. Nor does INSS have to do any calculation to 
show Suny' s pre-supplied rating of 0 for Package 9, as that value has also been 
previously stored* Hie rating Suny has previously supplied is not based on any changes 
in terms (issues and options), since there can be no changes during a mock negotiation. 



INSS does not have to plug in the correct data into any calculations, since all the data 
for issues, option values, and ratings has been entered before the mock negotiation 
began. Even the Pareto-optimal so!ution(s) for the players can be determined in 
advance using the ratings supplied by the playera. INSS only needs to wait until after 
the mock negotiation has completed to suggest the better solutions. 



It is also a simple matter for INSS to "track" the mock negotiation without analyzing the 
issues or options to understand their purpose or recognizing any changes in the issues 
or options- All it has to do is record in a file that player 1 "offered" predefined 
package 3 at time x, then player 2 "counter-offered" predefined package 4 at time y, 
and so on. 
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It is a simple matter to plot: the graphs shown on Page 11, since the graphs are only 
showing the players' predefined ratings for the sequence of packages that were 
"offered". Since the ratings have already been supplied in advance of any mock 
negotiation, they can simply be stored in a table or model. The content of the packages, 
does not change during the mock negotiation. 

This is quite dear from each graph. On the y axis or vertical side of the graph are shown 
the possible ratings, and on the x axis, or along the bottom of the graph are shown the 
dates when "offers" were exchanged- The two lines in each graph represent the "offers" 
from each party. The graph on the left shows the player Maki's {Misty's?} ratings for 
both sets* The graph on the right is different for the other player because it shows the 
sets of "offers" as they were rated by that player. 



Since all of the "offers'' which are rated and have their ratings graphed in the article 
were based on predefined packages, the graphs do not show any changes in terms, 
because there is no way for a player to change terms during a mock negotiation . Maki's 
rating for Package 9 will always.be 100, when that package is offered to Maki, no matter 
when it is offered. Similarly, Swry's rating for Package 9 will always be 0 when that 
package is offered to Suny, no matter when the package is offered. 



What the players are doing when they use the INSS simulator is presenting offers of 
predefined issue and option data, as described above. It should be noted that while the 
primary method INSS describes for selecting these predefined issues and options uses 
what it calls parallel negotiations in which the players select from complete packages to 
present an "offer", the INSS article describes on Page 3, an implementation of what it 
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calls Sequential negotiations, in which the players can select from a subset of predefined 
issues and options, so that a complete package does not need to be selected. That 
presumably, is why the players are also asked to rate the issues and their options 
separately as well as the different packages. In any case, there are still no changes in 
terms, since all the issues and options and ratings must still be predefined before the 
mock negotiation can begin. 



Applicants believe that a few lines in the article create the confusion on this point On 
Page 3 of the TNSS article, it states that INSS has a list of 9 options under the heading 
"Negotiation Protocol/' The list is preceded by a paragraph which states that " At 
present INSS allows to construct a protocol from three options listed below," In that 
list, Option 5 is "New values for continuous issues and Option 6 is New values for 
discrete and ordered issues and item 7 is New issues. 



Directly below this, the article states under the heading "How to choose? 7 ' : 

"Because the additional options listed above are not yet implemented you don't need to 
choose any specific protocol now- The three options already implemented provide you 
with additional flexibility in conducting negotiations/' 

These seem to suggest that users might be able to enter new values for issues under 
options 5 and 6- However, this also seems to say that only the first three options are 
implemented -not options 5, 6 and 7- However, even if they are deemed to have been 
implemented Applicants do not believe they change the above analysis. 

For example, in the discussion of " New values for continuous issues" the INSS article 
states: 
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"This option will allow to enter any value for a continuous issue other than the values 
specified at the beginning of negotiations. Tine continuues {sic} issue |sic} are those for 
which intermediate values make sense. Price, for example, is a continuous issue. The 
initial values may be $10, 420{sic| and $30. The option allows users to enter value {sic} 
of, for example, $15 which initialy {sic} had not been an option. 

Here we will also allow quasi-continuos {sic} issues which are naturally ordered but for 
which ratios or some other numbers make no sense. For example, such an issue is the 
project completion time or product delivery time. It does not make sense to talk about 
delivery time of 1.75 days. However, we will leave this problem to the users and 
assume that they will select numbers that make sense in their negotiations. 

An important problem that has to be mentioned here is the approximation of the 
utility The utility function that is determined durin g the pre-nepotiation phase has to be 
interpolated with new options being speqflqd/' 

[Emphasis added] 



While at first blush this might seem to suggest that a player can enter a new value 
during a mock negotiation, the last sentence makes it doubtful exactly what occurs. 

First for continuous issues;, a "new value" must be an intermediate value— Le, in the 
range of the previously defined values. If it is not an intermediate value, then all the 
ratings would have to be redone, in a pre-negotiation step- Recall that in the discussion 
of ratings, for each option supplied for an issue, one must be given the maximum value 
and one must be given a value of 0. Thus, if the ratings are to be useful at all, the only 
way a "new value" can be included for a continuous variable is if the new value is an 
intermediate value already in the range of the values which have been rated. This 
seems clear from the point made in the sentence "An important problem that has to be 
mentioned here is the approximation of die utility. The utility function that is 
determined during the pre-negotiation phase has to be interpolated with new options 
being specified." 
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The utility function (rating) that has been supplied for this issue and its previous 
options (values) has to be "interpolated" according to the above. Interpolation/ as 
defined in Webster's New World dictionary, item 3 Math, means "to estimate (a 
missing functional value) by taking a weighed average of known functional values at 
neighboring points, as in estimating a specific, missing intermediate value on a table, 
esp* a logarithmic or trigonometric table/ 7 Thus, it would appear that the INSS 
simulator or the NSS software would assign some rating to this intermediate value. 
However, it is not clear when that would be done — from the last sentence quoted it 
appears that this is done at the pre-negotiation phase. The article is ambiguous on this 
point. One way of reading this is that the interpolation might be done during a mock 
negotiation, but that is not what this appears to say- 
Apparently this feature, and the feature described as new values for discrete issues, 
would allow a user to modify an existing negotiation case. But apparently this would 
still have to be done before the mock negotiation occurs as the discussion of the impact 
on utility functions (ratings) makes dear and as the general discussion of the operation 
of INSS in constructing offers makes clear. This apparently is also the reason why a 
"new" continuous value must be an intermediate value (in the example shown, 
somewhere between 10 and 30), since that would also be the only way INSS could 
interpolate a rating for it 

The discussion of new discrete values makes it even dearer that the players must go 

back to the pre-negotiation stages to enter ratings, as is said at page 5: 

"Since there is no way to caculate {sic) the rating of new values based on the ratings of 
other options, the user would be required to enter the rating for any new discrete 
options/' 
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Ratings can only be entered during the pre-negotiation phase. Because of the way in 
which INSS describes how a player selects an offer from pre-packaged sets, it seems 
logical to conclude that options 5 and 6 only allow someone to modify an existing case 
before another mock negotiation begins. 



Similarly, option 7, New issues is described on Page 5 as: 
"New issues can be brought to the negotiation table during or even before the 
negotiation begins. This allows INSS users to make their own negotiation case online or 
extend greatly their current negotiation/' The only description of how this might be 
implemented, if it was ever implemented, has already been covered above in the 
discussion of creating a new case. A new case can be created by predefining all the 
issues and options ahead of time, as described on page 6 of the INSS reference, the very 
next page after this discussion. 

Another paragraph in the article which seems to suggest more than it actually of fers 
occurs on Page 2, under the heading "4. Negotiation support system": 

"INSS can also act as an NSS and support and facilitate real-life negotiations. The 

system is designed so that two parties who can agree on the issues and the possible 
options for those issues can negotiate over the Web, This is an obvious advantage when 
the parties are widely separated and may have difficulty arranging meetings. Using 
INSS is also helpful when post-settlement improvement is likely /'[Underlining 
emphasis added.] 

Again, at first blush, this seems to offer more scope for INSS, but it is only helpful if the 
"two parties can agree on the issues and the possible options for those issues." In INSS 
terms, this means the parties must create a new negotiation case which predefines all 
the values for the issues and options, as discussed above. Those familiar with real life 
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negotiations realize that it is unlikely that this will occur— most of a real world 
negotiation is about the value to be assigned to an issue as a negotiation progresses 
through a series of iterations. 

In any case, if the parties were to agree to a predefined set of values for the issues and 
options, the INSS system would still only be able to provide NSS support — that is, 
perform the Pareto-optimal determination based on the parties' ratings and perhaps 
suggest better packages. This might be helpful, but it is not a negotiations system. It is 
using a simulator for providing a negotiation support system function, not analyzing 
terms to understand their purpose or recognizing changes in terms. The authors of the 
INSS article dearly recognize this when they preface this discussion by saying that INSS 
can act as an NSS and su pport and facilitate (but not process) real-life negotiations. 



While it might be argued that simulators may sometimes anticipate functionality for 
purposes of patentability, applicants submit that in compu ter hardware and software 
development simulation tools have long been used to feign functionality that is still 
under development. If a manufacturer is developing a new operating system and new 
computer hardware at the same time, it is common for developers to use simulation 
tools to mimic functionality yet to be developed. The real operating system may be 
interfaced to a simulation model that pretends to operate as the hardware should, even 
if the hardware developers do not yet know how to implement the hardware. The 
operating system may pass a value to the simulation tool, which "pretends" to operate 
on it, but simply returns to the operating system a pre-programmed answer for that 
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value. The simulation tool could be said to be performing the same functionality as the 
as yet undeveloped hardware, without necessarily anticipating the later hardware 
features actually developed. 

In any event applicants respectfully submit that it has now been shown that INSS does 
not perform the same functionality recited in Applicants' daimed invention and does 
not anticipate, disclose, teach, nor render obvious Applicants' invention. The authors of 
the INSS paper do not describe it as a negotiation system. They are quite clear that it can 
be used as a game, a demonstration decision support system, a negotiation simulator, a 
demonstration negotiation support system or a research and training tool but they do 
not disclose or describe it as a negotiation system. 

The descriptions of how to create a case in order to use the simulator make it clear that 
all the possible values and issues must be identified,, specified, and predefined before a 
negotiation can be simulated. Since all the issues and options are defined in advance, 
the INSS software does not analyze terms to understand their purpose, nor does it 
recognizes changes in terms. It can only deal with pre-programmed issues and options. 



The description on Page 15 of how "offers " are constructed from the predefined, pre- 
rated packages, makes it dear that the players do not change any terms (issues and 
options) during their mode negotiation. They "offer" the predefined packages or 
subsets of them to each other until they reach an "agreement" in their mock negotiation. 
Since there are no changes in the terms during such, a mock negotiation, the INSS 
system cannot recognize changes* 
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The rejection also stated that, INSS recognizes which party is official J y waiting for a 
response, thereby recognizing a relative 'deciding entity/ See page 17, item 5 in 
particular/' 

Applicants respectfully disagree. First applicants can find no instance in the article 
which states that INSS recognizes which party is officially waiting for a response. 

In fact it would seem that the opposite is true— the INSS system is indifferent to which 
party to a mock negotiation is "officially" waiting for a response. At Page, 14> under 
the heading "1. Introduction" it states: 

"Participants in the negotiation are paired randomly and anonymously. Your partner 
may be from your city, country or from far away: a different country, a different 
continent. Please log in at lest once in two days to check whether there has been any 
activity. If you have provided an e-mail address, INSS will send you a note when your 
counterpart makes an offer, but it is better not to rely on these e-mails; do log in 
frequently/' 

Also, on Page 15, under th e heading "3-Using INSS", it states: 

"8. Make an offer to your partner using the menus in the offer-box. You can also send 
messages to your partner using the message-box* 

9. You will then have to wait for your partner to respond to your offer. Come back later 
(say the next day) and login to TNSS using the same negotiation name, user-name and 
password. INSS will show you whether your partner has sent you a response. Keep 
checking till you get a response. If you like, you can continue to send messages or new 
offers to your partner " [Underlining emphasis added] 

And the section cited in the rejection at Page 17, item 5 reads: 

I have sent an offer and my counterpart has not yet responded to it INSS shows 
me a "Waiting for response" page. Can I send a second offer instead of waiting? 
Yes, you can make consecutive offers without waiting for your counterpart. Click on the 
"Make an offer'' link in the menubar at the bottom of your page. There is also a link in 
the menubar that allows you to just "Send a message" instead of an offer/' 
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None of these suggests that BSfSS recognizes either player as "officially'' waiting for a 
response. Instead, because these cites suggest that either party can send multiple offers 
to the other without receiving any response, it is clear that there is no "official" waiting 
for response status that would suggest TNSS recognizes the one waiting as a relative 
deciding entity. Nor does the ability to send multiple offers make either party a 
deciding entity. 



Applicants respectfully submit that INSS does not recognize either player as a deciding 

entity, but, on the contrary, as is stated on Page 16, it would appear that the INSS 

simulator and NSS functions determine when negotiations are concluded: 

"11. When both you and your partner accept an offer, it is called an iagreementL {sic} 
INSS will tell you whether your agreement is "optimal", or whether it is possible to 
improve it and move towards a better agreement/' 

12. If INSS says you have reached the end of negotiation, fill out the post-negotiation 
questionnaire- Otherwise you have the choice of making more offers till you reach a 
better agreement or stopping at this point In any case fill out the questionnaire when 
you reach the end of the negotiation/' [Bolding emphasis added] 

From this, it would seem that neither party is a deciding entity* The INSS simulator 

decides whether a negotiation is ended* 



In summary, INSS as disclosed and described in the article cited does not in any way, 
perform the functionality of Applicants' claimed invention, nor would it tender it 
obvious. INSS is not a negotiations system. INSS does not analyze terms to understand 
th eir purpose, nor does it recognize changes in terms, nor does it recognize a party as a 
deciding entity. In fact to the extent that INSS requires predefinition of values it 
teaches away from Applicants' invention and relates to older art on simulation tools 
and decision theory, not to Applicants' invention. * 
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Consequently, Applicants respectfully submit that this basis for rejection has been 
overcome and that Claims 2-9 and 30-37 are in condition for Allowance. 



The Examiner rejected applicants' priority claim for the instant application, because the 
phrase "dynamic contracts manager" was not recited in any of the excerpts from the 
instant application or the specification of US Patent No. 6,141,653. The rejection further 
stated that the "Examiner would have to guess which, if any content in the parent 
applications is equivalent to this phrase. The Applicant has not set forth a clear cut 
example of support for the dynamic contracts manager in the parent applications such 
that the Examiner can with complete surety be convinced that the Applicant clearly 
envisioned and expressly described inclusion of a "dynamic contracts manager" as part 
of their invention at the time of filing of the parent applications/' 

Applicants respectfully disagree. As this application claims, the dynamic contracts 
manager supplies an initial set of terms for use by a user. As stated in the instant 
application at Page 79, this functionality operates in conjunction with the sponsored 
community function of the parent applications. 

Applicants respectfully submit that support for this functionality is found in the above 
referenced parent application at Col. 17, lines 46-47: 
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The sponsoring standards body establishes the community, prop<?ses initial standards, 
sets the rules for negotiations, encourages and monitors negotiations, and concludes 
with a finally agreed upon set of standards, with each step of each negotiation that 
occurred along the way archived, [Emphasis added] 



and again at Col. 20, lines 6-18: 

In a commerce community, the participants might be grouped as sellers 08grpa and 
buyers 08grpb. Seller participant 08grpa functions include automatically integrated 
remote Web authoring 214-02 and processing and administration 214-04. In remote 
Web authoring 214-02, the present invention allows a seller registering with the 
sponsored^communitv, to automatically create a seller's Website within the community, 
on completion of registration. The seller selects from se veral Website format templates 
provided bv the present invention and as the seller "fills in the blanks" in a selected 
template, the information is automatically integrated with the rest of the system, so that 
orders can be processed and accepted immediately .. JEmphasis added] 



and again at CoL 23, lines 61-67: 

In non commercial communities, such as standards communities or treaty negotiation 
communities, a sponsor 06 may wish to designate multiple deciding entities for each 
issue under consideration. In such an implementation, a sponsor 06 will usually want to 
establish more detailed rules for the ordering and processing of proposals. [Emphasis 
added] 

and again at Col. 24> lines 45-58: 

While some users of the present invention may want to install parts of it locally, it is 
another advantage of the present invention that it can also be used for a "one-time" or 
"nearly instantaneous" community negotiation. Turning briefly to Figure lc, if the 
sponsor of community CB is a standards body, it could create a community Website for 
the ne gotiation of a particular standard, enlist participants, and encourage and monitor 
the negotiations without anyone having to buy or install additional local hardware or 
software- When the negotiation is complete and the concluding agreed upon standards 
document can be made available to all concerned, the community could be 
"dismantled" and the participants could disband without wasting any hardware or 
software installations and expenses. [Emphasis added] 



and again at Col. 27, lines 43-64: 

In this diagram, it is assumed that a seller is registering for the first time with a 
sponsored commerce community . Other types of communities might vary this 
processing. First, at step 400, the seller chooses from one or more templates provided by 
multivariate negotiations engine system 02, based on the level of cost and functionality 
the seller desires. Sample website pages constructed from such templates by a 
hypothetical company named Exports, Inc., are shown in Figures 31a to 31d. 
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Next, at step 405 in Figure 4a file seller provides basic information as prompted by the 
system through a setup screen such as that shown in Figures 10-1-10-3. Portions of the 
demographic information collected there, along with other data collected later is 
automatically formatted along with the META tags and Meta Keywords for automatic 
submission to search engines. At step 410 in Figure 4a, the systemuptesents the 
community's standard license agreement and terms to the seller. If the seller agrees to 
the terms at decision block 425, processing continues, ff the seller does.noJLa gre&-the 
seller may proceed to block 420 to negotiate with spons or o^electnot to participate. 
[Emphasis added] 



and at Col. 15, lines 7-12: 

Still another aspect of the present invention is that sponsors c an perform many more 
functions, such as establisWgLStandards, basic contract terms f or the community (if 
desired), removing non-compliant participants, changing the structure of the seller and 
buyer databases, and so on than existing systems allow any administrator to perform, 
[Emphasis added] 



Applicants believe that the above excerpts provide ample support for a dynamic 
contracts manager supplying initial terms for use by a user in the parent applications. 
While admittedly the exact phrase "dynamic contract manager" is not used in the 
parent applications, this functionality is clearly disclosed in the above excerpts. 
Consequently, Applicants respectfully submit that the instant application be granted 
the priority date claimed. 



Applicants respectfully submit that all bases for rejection have been overcome, that the 
instant application should be granted the priority date claimed and that Claims 2-9 and 
30-37 are in condition for allowance. Reconsideration of all the claims is requested. 
Allowance of Claims 2-9 and 30-37 at an early date is solicited. 



Applicants ' Attorney respectfully requests that if she can be of any further assistance in 
putting all the claims in condition for allowance that she be reached by telephone at 
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508-653-8143 in order to discuss the application with the Examiner, so that any new 
objections or rejections may be addressed. 

Respectfully submitted. 



Maureen Stretch 
Reg. No. 29,447 
26 Charles Street 
Natick, MA 01760 

3/9/2006 
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